Tcf362fT131417 PRIVACY GUIDES T969389~/privacy
T969389DNS Overview
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
T969389Sections: Tcf362fWhat is DNS? Tcf362fWhat is "encrypted DNS"? Tcf362fWhat can an outside party see?
The Domain Name System (https://en.wikipedia.org/wiki/Domain_Name_System) is the 'phone book of the Internet'. DNS translates domain names to IP addresses so browsers and other services can load Internet resources, through a decentralized network of servers.
What is DNS?
When you visit a website, a numerical address is returned. For example, when you visit 'privacyguides.org', the address '192.98.54.105' is returned.
DNS has existed since the early days (https://en.wikipedia.org/wiki/Domain_Name_System#History) of the Internet. DNS requests made to and from DNS servers are not generally encrypted. In a residential setting, a customer is given servers by the ISP via DHCP (https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol).
Unencrypted DNS requests are able to be easily surveilled and modified in transit. In some parts of the world, ISPs are ordered to do primitive DNS filtering (https://en.wikipedia.org/wiki/DNS_blocking). When you request the IP address of a domain that is blocked, the server may not respond or may respond with a different IP address. As the DNS protocol is not encrypted, the ISP (or any network operator) can use DPI (https://en.wikipedia.org/wiki/Deep_packet_inspection) to monitor requests. ISPs can also block requests based on common characteristics, regardless of which DNS server is used.
Below, we discuss and provide a tutorial to prove what an outside observer may see using regular unencrypted DNS and encrypted DNS.
Unencrypted DNS
1. Using 'tshark' (https://wireshark.org/docs/man-pages/tshark.html) (part of the Wireshark (https://en.wikipedia.org/wiki/Wireshark) project) we can monitor and record internet packet flow. This command records packets that meet the rules specified:
tshark -w /tmp/dns.pcap udp port 53 and host 1.1.1.1 or host 8.8.8.8
2. We can then use 'dig' (https://en.wikipedia.org/wiki/Dig_(command)) (Linux, macOS, etc.) or 'nslookup' (https://en.wikipedia.org/wiki/Nslookup) (Windows) to send the DNS lookup to both servers. Software such as web browsers do these lookups automatically, unless they are configured to use encrypted DNS.
=== "Linux, macOS"
dig +noall +answer privacyguides.org @1.1.1.1
dig +noall +answer privacyguides.org @8.8.8.8
=== "Windows"
nslookup privacyguides.org 1.1.1.1
nslookup privacyguides.org 8.8.8.8
3. Next, we want to analyze (https://wireshark.org/docs/wsug_html_chunked/ChapterIntroduction.html#ChIntroWhatIs) the results:
=== "Wireshark"
wireshark -r /tmp/dns.pcap
=== "tshark"
tshark -r /tmp/dns.pcap
If you run the Wireshark command above, the top pane shows the "frames (https://en.wikipedia.org/wiki/Ethernet_frame)", and the bottom pane shows all the data about the selected frame. Enterprise filtering and monitoring solutions (such as those purchased by governments) can do the process automatically, without human interaction, and can aggregate those frames to produce statistical data useful to the network observer.
| No. | Time | Source | Destination | Protocol | Length | Info |
|-----|----------|-----------|-------------|----------|--------|------------------------------------------------------------------------|
| 1 | 0.000000 | 192.0.2.1 | 1.1.1.1 | DNS | 104 | Standard query 0x58ba A privacyguides.org OPT |
| 2 | 0.293395 | 1.1.1.1 | 192.0.2.1 | DNS | 108 | Standard query response 0x58ba A privacyguides.org A 198.98.54.105 OPT |
| 3 | 1.682109 | 192.0.2.1 | 8.8.8.8 | DNS | 104 | Standard query 0xf1a9 A privacyguides.org OPT |
| 4 | 2.154698 | 8.8.8.8 | 192.0.2.1 | DNS | 108 | Standard query response 0xf1a9 A privacyguides.org A 198.98.54.105 OPT |
An observer could modify any of these packets.
What is "encrypted DNS"?
Encrypted DNS can refer to one of a number of protocols, the most common ones being DNSCrypt, DNS over TLS, and DNS over HTTPS.
DNSCrypt
DNSCrypt (https://en.wikipedia.org/wiki/DNSCrypt) was one of the first methods of encrypting DNS queries. DNSCrypt operates on port 443 and works with both the TCP or UDP transport protocols. DNSCrypt has never been submitted to the Internet Engineering Task Force (IETF) (https://en.wikipedia.org/wiki/Internet_Engineering_Task_Force) nor has it gone through the Request for Comments (RFC) (https://en.wikipedia.org/wiki/Request_for_Comments) process, so it has not been used widely outside a few implementations (https://dnscrypt.info/implementations). As a result, it has been largely replaced by the more popular DNS over HTTPS.
DNS over TLS (DoT)
DNS over TLS (https://en.wikipedia.org/wiki/DNS_over_TLS) is another method for encrypting DNS communication that is defined in RFC 7858 (https://datatracker.ietf.org/doc/html/rfc7858). Support was first implemented in Android 9, iOS 14, and on Linux in systemd-resolved (https://freedesktop.org/software/systemd/man/resolved.conf.html#DNSOverTLS=) in version 237. Preference in the industry has been moving away from DoT to DoH in recent years, as DoT is a complex protocol (https://dnscrypt.info/faq) and has varying compliance to the RFC across the implementations that exist. DoT also operates on a dedicated port 853 which can be blocked easily by restrictive firewalls.
DNS over HTTPS (DoH)
DNS over HTTPS (https://en.wikipedia.org/wiki/DNS_over_HTTPS), as defined in RFC 8484 (https://datatracker.ietf.org/doc/html/rfc8484), packages queries in the HTTP/2 (https://en.wikipedia.org/wiki/HTTP/2) protocol and provides security with HTTPS. Support was first added in web browsers such as Firefox 60 and Chrome 83.
Native implementation of DoH showed up in iOS 14, macOS 11, Microsoft Windows, and Android 13 (however, it won't be enabled by default (https://android-review.googlesource.com/c/platform/packages/modules/DnsResolver/+/1833144)). General Linux desktop support is waiting on the systemd implementation (https://github.com/systemd/systemd/issues/8639) so Tcf362finstalling third-party software is still required.
Native Operating System Support
Android
Android 9 and above support DNS over TLS. The settings can be found in: Settings → Network & Internet → Private DNS.
Apple Devices
The latest versions of iOS, iPadOS, tvOS, and macOS, support both DoT and DoH. Both protocols are supported natively via configuration profiles (https://support.apple.com/guide/security/configuration-profile-enforcement-secf6fb9f053/web) or through the DNS Settings API (https://developer.apple.com/documentation/networkextension/dns_settings).
After installation of either a configuration profile or an app that uses the DNS Settings API, the DNS configuration can be selected. If a VPN is active, resolution within the VPN tunnel will use the VPN's DNS settings and not your system-wide settings.
Apple does not provide a native interface for creating encrypted DNS profiles. Secure DNS profile creator (https://dns.notjakob.com/tool.html) is an unofficial tool for creating your own encrypted DNS profiles, however they will not be signed. Signed profiles are preferred; signing validates a profile's origin and helps to ensure the integrity of the profiles. A green "Verified" label is given to signed configuration profiles. For more information on code signing, see About Code Signing (https://developer.apple.com/library/archive/documentation/Security/Conceptual/CodeSigningGuide/Introduction/Introduction.html).
Linux
'systemd-resolved', which many Linux distributions use to do their DNS lookups, doesn't yet support DoH (https://github.com/systemd/systemd/issues/8639). If you want to use DoH, you'll need to install a proxy like Tcf362fdnscrypt-proxy and configure it (https://wiki.archlinux.org/title/Dnscrypt-proxy) to take all the DNS queries from your system resolver and forward them over HTTPS.
What can an outside party see?
In this example we will record what happens when we make a DoH request:
1. First, start 'tshark':
tshark -w /tmp/dns_doh.pcap -f "tcp port https and host 1.1.1.1"
2. Second, make a request with 'curl':
curl -vI --doh-url https://1.1.1.1/dns-query https://privacyguides.org
3. After making the request, we can stop the packet capture with CTRL + C.
4. Analyze the results in Wireshark:
wireshark -r /tmp/dns_doh.pcap
We can see the connection establishment (https://en.wikipedia.org/wiki/Transmission_Control_Protocol#Connection_establishment) and TLS handshake (https://cloudflare.com/learning/ssl/what-happens-in-a-tls-handshake) that occurs with any encrypted connection. When looking at the "application data" packets that follow, none of them contain the domain we requested or the IP address returned.
T969389Part 1/3 Tcf362fNext
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Tcf362fGuides Home Tcf362fSearch Guides
Ta6a49eContent from Privacy Guides (privacyguides.org), commit 0295ab4.
Ta6a49eLicense: CC BY-SA 4.0 - creativecommons.org/licenses/by-sa/4.0